FIG. 1 shows a yield analysis tool infrastructure that exists in an integrated circuit (“IC”) manufacturing or fabrication factory (a “semiconductor fab” or “fab”) in accordance with the prior art. As shown in FIG. 1, mask shop 1000 produces reticle 1010. As further shown in FIG. 1, Work-in-Progress tracking system 1020 (“WIP tracking system 1020”) tracks wafers as they progress through various processing steps in the fab that are used to fabricate (and test) ICs on a wafer or a substrate (the terms wafer and substrate are used interchangeably to refer to semiconductor wafers, or substrates of all sorts including, for example, and without limitation, glass substrates). For example, and without limitation, WIP tracking system 1020 tracks wafers through: implant tools 1030; diffusion, oxidation, deposition tools 1040; chemical mechanical planarization tools 1050 (“CMP tools 1050”); resist coating tools 1060 (for example, and without limitation, tools for coating photoresist); stepper tools 1070; developer tools 1080; etch/clean tools 1090; laser test tools 1100; parametric test tools 1110; wafer sort tools 1120; and final test tools 1130. These tools represent most of the tools that are used in the fab to produce ICs. However, this enumeration is meant to be illustrative, and not exhaustive.
As further shown in FIG. 1, a fab includes a number of systems for obtaining tool level measurements, and for automating various processes. For example, as shown in FIG. 1, tool level measurement and automation systems include tool databases 1210 to enable tool level measurement and automation tasks such as, for example, process tool management (for example, process recipe management), and tool sensor measurement data collection and analysis. For example, and without limitation, illustratively, PC server 1230 downloads process recipe data to tools (through recipe module 1233), and receives tool sensor measurement data from tool sensors (from sensors module 1235), which process recipe data and tool sensor measurement data are stored, for example, in tool databases 1210.
As further shown in FIG. 1, the fab includes a number of process measurement tools. For example, defect measurement tools 1260 and 1261; reticle defect measurement tool 1265; overlay defect measurement tool 1267; defect review tool 1270 (“DRT 1270”); CD measurement tool 1280 (“critical dimension measurement tool 1280”); and voltage contrast measurement tool 1290, which process measurement tools are driven by process evaluation tool 1300.
As further shown in FIG. 1, application specific analysis tools drive certain process measurement tools. For example, defect manager tool 1310 analyzes data produced by defect measurement tools 1260 and 1261; reticle analysis tool 1320 analyzes data produced by reticle defect measurement tool 1265; overlay analysis tool 1330 analyzes data produced by overlay defect measurement tool 1267; CD analysis tool 1340 analyzes data produced by CD measurement tool 1280, and testware tool 1350 analyzes data produced by laser test tools 1100, parametric test tools 1110, wafer sort tools 1120, and final test tools 1130.
As further shown in FIG. 1, database tracking/correlation tools obtain data from one or more of the application specific analysis tools over a communications network. For example, statistical analysis tools 1400 obtain data from, for example, defect manager tool 1310, CD analysis tool 1340, and testware tool 1350, and stores the data in relational database 1410.
Finally, yield management methodologies are applied to data stored in data extraction database 1420, which data is extracted from WIP tracking system 1020, and tool databases 1210 over the communications network.
Yield management systems used in the fab in the prior art suffer from many problems. FIG. 2 illustrates a prior art process that is utilized in the fab, which prior process is referred to herein as end-of-line monitoring. End-of-line monitoring is a process that utilizes a “trailing indicators” feedback loop. For example, as shown at box 2000 of FIG. 2, trailing indicators such as, for example, and without limitation, low yield, poor quality, and/or slow speed of devices are identified. Then, at box 2010, “bad lot” metrics (i.e., measurements related to wafer lots that produced the trailing indicators) are compared to specifications for the metrics. If the metrics are “out of spec,” processing continues at box 2030 where an action is taken on an “out-of-spec” event, and feedback is provided to process control engineers to correct the “out-of-spec” condition. If, on the other hand, the metrics are “in-spec,” processing continues at box 2020 where plant knowledge of past history for failures is analyzed. If this is a previously identified problem, processing continues at box 2040, otherwise (i.e., there is no prior knowledge), processing continues at box 2050. At box 2040, actions are taken in light of lot or tool comments regarding a previously identified problem, and feedback is provided to the process control engineers to take the same type of action that was previously taken. As shown at box 2050, a failure correlation is made to tool or device process historical data. If a correlation is found, processing continues at box 2060, otherwise, if no correlation is found, processing continues at box 2070. At box 2060, the “bad” tool or device process is “fixed,” and feedback is provided to the process control engineers. At box 2070, a factory maintenance job is performed.
There are several problems associated with the above-described end-of-line monitoring process. For example: (a) low yield is often produced by several problems; (b) “spec” limits are often set as a result of unconfirmed theories; (c) knowledge of past product failure history is often not documented or, if it is documented, the documentation is not widely distributed; (d) data and data access is fragmented; and (e) a working hypothesis must be generated prior to performing a correlation analysis, the number of correlations is very large, and resources used to perform the correlation analysis is limited.
For example, a typical engineering process of data feed back and problem fixing typically entails the following steps: (a) define the problem (a typical time for this to occur is about 1 day); (b) select key analysis variables such as, for example, percentage of yield, percentage of defects, and so forth (a typical time for this to occur is about 1 day); (c) form an hypothesis regarding selected key analysis variable anomalies (a typical time for this to occur is about 1 day); (d) rank hypotheses using various “gut feel” methods (a typical time for this to occur is about 1 day); (e) develop experimental strategies and an experimental test plan (a typical time for this to occur is about 1 day); (f) run the experiments and collect data (a typical time for this to occur is about 15 days); (g) fit the model (a typical time for this to occur is about 1 day); (h) diagnose the model (a typical time for this to occur is about 1 day); (i) interpret the model (a typical time for this to occur is about 1 day); and (j) run confirmation tests to verify an improvement (a typical time for this to occur is about 20 days), or if there is no improvement, run the next experiment starting at (c), typically involving five (5) iterations. As a result, a typical time to fix a problem is about seven (7) months.
As line widths shrink, and newer technology and materials are being used to manufacture ICs (for example, copper metallization, and new low-k dielectric films), reducing defectivity (be it process or contamination induced) is becoming increasingly more important. Time-to-root-cause is key to overcoming defectivity. These issues are made no easier by a transition to 300 mm wafers. Thus, with many things converging simultaneously, yield ramping is becoming a major hurdle.
In addition to the above-identified problems, a further problem arises in that semiconductor fabs spend a large amount of their capital on defect detection equipment and defect data management software in an effort to monitor defectivity, and continuously reduce defect densities. Current prior art techniques in defect data management software entail developing one or more of the following deliverables: (a) defect trends (for example, paretos by defect type and size); (b) wafer level defect versus yield charts; and (c) kill ratio on an ad hoc and manual basis by type and size. For each of these deliverables, a main drawback is that a user has to have prior knowledge of what he/she wants to plot. However, due to the magnitude of the data, the probability of the user trending a root cause is low. Moreover, even if charts were generated for every variable, given the large number of charts, it would be virtually impossible for the user to analyze every one of such charts.
In addition to the above-identified problems, a further problem arises in that much of the data utilized in the semiconductor fab is “indirect metrology data.” The term “indirect metrology” in this context indicates data gathering on indirect metrics, which indirect metrics are assumed to relate in predictable ways to manufacturing process within the fab. For example, after a metal line is patterned on an IC, a critical dimension scanning electron microscope (“CD-SEM”) might be used to measure a width of the metal line at a variety of locations on a given set of wafers. A business value is assigned to a metrology infrastructure within a semiconductor fab that is related to how quickly a metrology data measurement can be turned into actionable information to halt a progression of a process “gone bad” in the fab. However, in practice, indirect metrology identifies a large number of potential issues, and these issues often lack a clear relationship to specific or “actionable” fab processing tools or processing tool processing conditions. This lack of a clear relationship between the processing toolset and much of a semiconductor fab's indirect metrology results in a significant investment in engineering staffing infrastructure, and a significant “scrap” material cost due to the unpredictable timeframe required to establish causal relationships within the data.
In addition to metrology, within the last few years a large amount of capital has been spent on deploying data extraction systems designed to record operating conditions of semiconductor wafer processing tools during the time a wafer is being processed. Although temporal based, process tool data is now available for some fraction of processing tools in at least some fabs, use of the data to optimize processing tool performance relative to the ICs being produced has been limited. This is due to a disconnect between how IC performance data is represented relative to how processing tool temporal data is represented. For example, data measurements on ICs are necessarily associated with a given batch of wafers (referred to as a lot),or a given wafer, or a given subset of ICs on the wafer. On the other hand, data measurements from processing tool temporal data are represented as discrete operating conditions within the processing tool at specific times during wafer processing. For example, if a processing tool has an isolated processing chamber, then chamber pressure might be recorded each millisecond while a given wafer remains in the processing chamber. In this example, the chamber pressure data for any given wafer would be recorded as a series of 1000's of unique measurements. This data format cannot be “merged” into an analysis table with a given IC data metric because the IC data metrics are single discrete measurements. The difficulty associated with “merging” processing tool temporal data and discrete data metrics has resulted in limited use of processing tool temporal data as a means to optimize factory efficiency.
In addition to the above-identified problems, a further problem arises that involves the use of relational databases to store the data generated in a fab. Relational databases, such as, for example, and without limitation, ORACLE and SQL Server, grew out of a need to organize and reference data that has defined or assigned relationships between data elements. In use, a user (for example, a programmer) of these relational database technologies supplies a schema that pre-defines how each data element relates to any other data element. Once the database is populated, an application user of the database makes queries for information contained in the database based on the pre-established relationships. In this regard, prior art relational databases have two inherent issues that cause problems when such relational databases are used in a fab. The first issue is that a user (for example, aprogrammer) must have an intimate knowledge of the data prior to creating specific schema (i.e., relationships and database tables) for the data to be modeled. The schema implements controls that specifically safe guard the data element relationships. Software to put data into the database, and application software to retrieve data from the database, must use the schema relationship between any two elements of data in the database. The second issue is that, although relational databases have excellent TPS ratings (i.e., transaction processing specifications) for retrieving small data transactions (such as, for example, banking, airline ticketing, and so forth), they perform inadequately in generating large data sets in support of decision support systems such as data warehousing, and data mining required for, among other things, yield improvement in a fab.
In addition to the above-identified problems, a further problem arises as a result of prior art data analysis algorithms that are used in the semiconductor manufacturing industry to quantify production yield issues. Such algorithms include linear regression analysis, and manual application of decision tree data mining methods. These algorithms suffer from two basic problems: (a) there is almost always more than one yield impacting issue within a given set of data; however, these algorithms are best used to find “an” answer rather than quantify a suite of separate yield impacting issues within a given fab; and (b) these algorithms are not able to be completely automated for “hands off” analyses; i.e., linear regression analysis requires manual preparation and definition of variable categories prior to analysis, and the decision tree data mining requires a “human user” to define a targeted variable within the analysis as well as to define various parameters for the analysis itself.
In addition to the above-identified problems, a further problem arises in data mining significantly large data sets. For example, in accordance with prior art techniques, data mining significantly large data sets has been possible only after utilizing some level of domain knowledge (i.e., information relating to, for example, what fields in a stream of data represent “interesting” information) to filter the data set to reduce the size and number of variables within the data to be analyzed. Once this reduced data set is produced, it is mined against a known analysis technique/model by having experts define a value system (i.e., a definition of what is important), and then guess at “good questions” that should drive the analysis system. For this methodology to be effective, the tools are typically manually configured, and manipulated by people who will ultimately evaluate the results. These people are usually the same people responsible for the process being evaluated, since it is their industry expertise (and more precisely, their knowledge of the particular processes) that is needed to collect the data and to form proper questions used to mine the data set. Burdening these industry experts with the required data mining and correlation tasks introduces inefficiencies in use of their time, as well as inconsistencies in results obtained from process to process, since the process of data mining is largely driven by manual intervention. Ultimately, even when successful, much of the “gains” have been lost or diminished. For example, the time consuming process of manually manipulating the data and analysis is costly, in man hours and equipment, and if the results are not achieved early enough, there is not enough time to implement discovered changes.
In addition to the above-identified problems, a further problem arises in as follows. An important part of yield enhancement and factory efficiency improvement monitoring efforts are focused on correlations between end-of-line functional test data, inline parametric data, inline metrology data, and specific factory process tools used to fabricate ICs. In carrying out such correlations, it is necessary to determine a relationship between a specified “numeric column of data” relative to all of the columns of factory processing tool data (which processing tool data are pre-presented as categorical attributes). A good correlation is defined by a specific column of processing tool (i.e., categorical) data having one of the categories within the column correlate to an undesirable range of values for a chosen numeric column (i.e., referred to as a Dependent Variable or “DV”). The goal of such an analysis is to identify a category (for example, a factory process tool) suspected of causing undesirable DV readings, and to remove it from the fab processing flow until such time as engineers can be sure the processing tool is operating correctly. Given the vast number of tools and “tool-like” categorical data within semiconductor fab databases, it is difficult to isolate a rogue processing tool using manual spreadsheet searching techniques (referred to as “commonality studies). Despite this limitation, techniques exist within the semiconductor industry to detect bad processing tools or categorical process data. For example, this may be done by performing lot commonality analysis. However, this technique requires prior knowledge of a specific process layer, and it can be time consuming if a user does not have a good understanding of the nature of the failure. Another technique is to use advanced data mining algorithms such as neural networks or decision trees. These techniques can be effective, but extensive domain expertise required in data mining makes them difficult to set up. In addition, these data mining algorithms are known to be slow due to the large amount of algorithm overhead required with such generic data analysis techniques. With the above-mentioned analysis techniques, the user typically spends more time trying to identify a problem via a rudimentary or complex analysis than spending effort contributing to actual fixing of the bad processing tool after it is found.
Lastly, in addition to the above-identified problems, a further problem arises as follows. Data mining algorithms such as neural networks, rule induction searches, and decision trees are often more desirable methodologies when compared to ordinary linear statistics, as pertains to searching for correlations within large datasets. However, when utilizing these algorithms to analyze large data sets on low cost hardware platforms such as Window 2000 servers, several limitations occur. Of primary concern among these limitations is the utilization of random access memory and extended CPU loading required by these techniques. Often, a neural network analysis of a large semiconductor manufacturing dataset (for example, >40 Mbytes) will persist over several hours, and may even breach the 2 Gbyte RAM limit for the Windows 2000 operating system. In addition, rule induction or decision tree analysis on these large datasets, while not necessarily breaching the RAM limit for a single Windows process, may still persist for several hours prior to the analysis' being complete.
There is a need in the art to solve one or more of the above-described problems.